In present computer systems it is common for a user working on one computer to access applications residing on another computer, such as a mainframe computer, as depicted in FIG. 1. Emulation software running on a processor 109A of a user's computer 110 enables the computer 110 to communicate with the mainframe computer 130 in order to access an application 132 residing on the mainframe computer 130. The emulation software running on the processor 109A of the computer 110 is referred to as an emulator 112. For security, a user 102 supplies a user identification (“user ID”) and a password to gain access to an application 132 residing on the mainframe computer 130.
Information is passed between the user's computer 110 and the mainframe computer 130 over a computer network connection 115 using an outbound data stream 113A (data sent from the mainframe computer 130 to the user's computer 110) and an inbound data stream 113B (data sent from the user's computer 110 to the mainframe computer 130). FIG. 1A depicts an exemplary representation of the contents of an outbound data stream 113A. The outbound data stream 113A contains a stream header 116 and data fields 117–119. The stream header 116 contains information about the data fields 117–119 (e.g., the number of data fields which follow the stream header 116 and the number of bits in each data field) and the data fields 117–119 contain information such as user ID information residing in a user identification (ID) data field 117 and password field information residing in a password data field 119.
Each data field 117–119 within the outbound data stream 113A contains an attribute field 117A–119A that identifies a property or characteristic of its respective field 117–119. The user ID data field 117 and the password data field 119 contain information which is used by the emulator 112 running on the user's computer 110 to display, as depicted in FIG. 2A, a user ID display field 123 and a password display field 125, respectively, on an emulator screen 122A within an emulator window 122 for display on the user's computer monitor 111 (FIG. 1). The user 102 then supplies a user ID and a password to the mainframe computer 130 by typing character strings comprising the user ID and password into the appropriate fields of the emulator screen 122A and pressing an [ENTER] key to send the typed information to the mainframe computer 130.
One property which is often associated with the password data field 119 (FIG. 1A), which contains information for generating the password display field 125 (FIG. 2A), is a non-display attribute (ND att.) 119A that prompts the emulator 112 to not display the actual text which the user 102 types into a password display field 125. For example, if the user's password is [SUMMER] the emulator may display an asterisk (*) for each character input by a user 102 into the password display field 125 on the screen 122A, e.g., [******]. Conversely, the user ID data field 117, which contains information for generating the user ID display field 123, generally has a display attribute (D att.) 117A that prompts the emulator 112 to display the actual text which the user 102 types into the user ID display field 123.
In addition to the user ID display field 123 and the password display field 125 depicted in the emulator window 122 of FIG. 2A, the emulator screen 122A contains a user ID request 123A (e.g., ENTER USERID) and a password request 125A (e.g., ENTER PASSWORD) that identifies the user ID display field 123 and the password display field 125, respectively, for the user 102. The user 102 then supplies the user ID and the password by typing the user ID and password into the appropriate display field 123,125. Alternatively, the user ID and password are entered into display fields residing on different screens.
The user ID and password are supplied to the application 132 through the emulator 112 each time that application 132 is accessed even if the user 102 is currently using another application (e.g. application 131 or 133) on the mainframe 130 and seeks to access the application 132 at the same time. Supplying the user ID and password each time the application 132 is accessed, however, is cumbersome and often unnecessary given modern security techniques such as the secure socket layer (SSL) protocol implemented in many computer systems.
As depicted in FIG. 1, many emulators 112 contain macros 114 which can be used to supply the user ID and password for the application 132. A macro 114 permits a sequence of commands or keystrokes to be stored in a computer memory 109B and then recalled with a single command or keystroke at a later date. Often, a user 102 will store the user ID and password in a logon macro 114A to facilitate accessing the application 132. The user 102 then need only execute a single command or keystroke to supply the user ID and password to the application 132. Generally, a header 126 of the emulator window 122 (FIG. 2A) will contain a record button 126A and a play button 126B to facilitate the storage and playback of macros 114 by the emulator 112.
Storing the user ID and password in the logon macro 114A, however, leads to potential security problems. Security problems arise from the ability of persons other than the user 102 who gain access to the user's computer 110 to obtain the user ID and password of the user 102 by examining the logon macro 114A stored in the computer's memory 109B, or by executing the logon macro 114A on the user's computer 110 when the user 102 is elsewhere.
Emulation systems have been created which attempt to address the cumbersome logon process and the security issues presented by traditional macros 114 in prior art emulation systems. An example of these emulation systems are the emulation systems which support the IBM® Express Logon Feature (ELF) referred to in “Setting up and Using the IBM® Express Logon Feature,”© Copyright International Business Machines Corporation 2000, incorporated fully herein by reference.
In emulation systems incorporating ELF, security is handled by system implemented security measures such as the secure socket layer (SSL) protocol. In order to eliminate the need for the user 102 to input the user ID and password information for an application 132, a logon macro 114A must still be created; however, the user ID and password are not stored. Instead of storing the user ID and password, a logon macro 114A is created having placeholders for the user ID and password. The advanced emulation systems then rely on the system implemented security measures in a known manner to recognize the placeholders and assign the equivalent of a user ID and password which is acceptable to the application 132.
In order to replace the user ID and password with placeholders, the location of the user ID display field 123 and the password display field 125 (FIG. 2A) must first be determined so that information input into those fields can be appropriately modified for generating the logon macro 114A (FIG. 1). Identifying the user ID display field 123 and the password display field 125 requires a number of steps to be performed by the user 102 which are cumbersome and may require that the user 102 obtain special training to perform the identifying steps. Systems seeking to facilitate this process assist the user 102 in manually identifying the user ID display field 123 and the password display field 125 for the system.
One method for identifying the location of the user ID display field 123 and the password display field 125 manually involves the use of display windows, such as those displayed in FIGS. 2B and 2C, which are displayed on a monitor 111 of a user's computer 110 during the creation of a logon macro 114A. In FIG. 2B a window containing check boxes 134B and an instruction 134A stating “[d]oes this session screen contain a user ID field used to logon to the host application?,” are displayed to the user 102 during the creation of a logon macro 114A. Upon encountering the screen 122A (FIG. 2A) on the monitor 111 where the user ID is requested, the user 102 selects the box labeled [YES] 134C and then selects the [NEXT] button 134D on the display window of FIG. 2B.
After selecting the [NEXT] button 134D, indicating to the system that a screen 122A containing the user ID display field 123 is displayed on a user's monitor 111, the system generates the display window depicted in FIG. 2C. The display window of FIG. 2C provides the user 102 with instructions 138A for identifying the location of the user ID display field 123 within the screen 122A. The user ID display field 123 is located in a specific location on screen 122A which may be designated by a row number and a column number. The row number and column numbers for the user ID display field 123 are then stored so that the user ID (or a user ID replacement, e.g., a placeholder) can be placed in the appropriate user ID display field 123 when the logon macro 114A is played back at a later date. In the present example, the row and column numbers are stored by inserting the row and column numbers into the appropriate boxes in a position field 138B.
The user 102 may select the [CURRENT] button 138C to propagate the row and column location of the cursor on the screen 122A into the position fields 138B. In this manner, the user 102 may cause the appropriate row and column numbers to be placed into the position fields 138B simply by placing the cursor in the first position of the user ID display field 123 (FIG. 2A) and selecting the [CURRENT] button 138C. Alternatively, the user 102 may fill in the position fields 138B manually. After the position fields 129B are filled in, the user 102 inputs the user ID into the user ID box 129D and selects the [NEXT] button 129E. This process is used to identify the screen and location of the user ID display field 123. The user 102 then follows a similar process to determine the screen and location of the password display field 125.
Present systems which attempt to identify the location of the user ID display field 123 and the password display field 125, such as the method used in recently developed emulation systems, are cumbersome for a user to learn and use, and require time and effort for training. In addition, time and effort are required for the user 102 to manually assist in identifying the locations of the user ID display field 123 and the password display field 125. Accordingly, a system which is able to automatically identify the user ID display field 123 and the password display field 125 displayed on a computer monitor 111 by an emulator 112 without intervention from the user 102 would be useful.